-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Clippy #114729
Update Clippy #114729
Conversation
This is necessary for closure captures in 2021 edition, as they capture individual fields, not the full mentioned variables. So it may try to capture a field of an opaque (because the hidden type is known to be something with a field).
…param-env, r=oli-obk Remove `constness` from `ParamEnv` This should be replaced by keyword generics/effects. cc rust-lang#110395 r? `@oli-obk`
…arn, r=compiler-errors make `noop_method_call` warn by default r? `@compiler-errors`
…lstrieb Rename and allow `cast_ref_to_mut` lint This PR is a small subset of rust-lang#112431, that is the renaming of the lint (`cast_ref_to_mut` -> `invalid_reference_casting`). BUT also temporarily change the default level of the lint from deny-by-default to allow-by-default until rust-lang#112431 is merged. r? `@Nilstrieb`
…rkingjubilee Mark `map_or` as `#[must_use]` I don't know what else to say. r? libs
… colored and uncolored printing
[`unnecessary_mut_passed`]: don't lint in macro expansions Fixes rust-lang#11268 changelog: [`unnecessary_mut_passed`]: don't lint in macro expansions
Alphabetically order arms in `methods/mod.rs` match changelog: none just order the arms in the match block
[`unwrap_used`]: Do not lint unwrapping on `!` or never-like enums Fixes rust-lang#11245 changelog: [`unwrap_used`]: Do not lint unwrapping on `!` or never-like enums changelog: [`expect_used`]: Do not lint unwrapping on `!` or never-like enums
Suppress `question_mark` warning if `question_mark_used` is not allowed Closes rust-lang#11283 changelog: [`question_mark`]: Don't lint if `question_mark_used` is not allowed
[`ptr_as_ptr`]: Take snippet instead of pretty printing type Fixes rust-lang#11278 changelog: [`ptr_as_ptr`]: Include leading `super`s in suggestion
Co-authored-by: Dirkjan Ochtman <[email protected]>
…=xFrednet,djc [`slow_vector_initialization`]: clarify why `Vec::new()` + resize is worse rust-lang#11198 extended this lint to also warn on `Vec::new()` + `resize(0, len)`, but did not update the lint documentation, so it left some confused (rust-lang/rust-clippy#10938 (comment)). This PR should make it a bit more clear. (cc `@djc` `@vi` what do you think about this?) <details> <summary>More details</summary> Godbolt for `Vec::new()` + `.resize(x, 0)`: https://godbolt.org/z/e7q9xc9rG The resize call first does a normal allocation (`__rust_alloc`): ```asm alloc::raw_vec::finish_grow: ... cmp qword ptr [rcx + 8], 0 je .LBB1_7 ; if capacity == 0 -> LBB1_7 .LBB1_7: ... call qword ptr [rip + __rust_alloc@GOTPCREL] ``` *Then* a memset for zero initialization: ```asm example::f: ... xor esi, esi ; 0 call qword ptr [rip + memset@GOTPCREL] ``` ------------ Godbolt for `vec![0; len]`: https://godbolt.org/z/M3vr53vWY Important bit: ```asm example::f: ... call qword ptr [rip + __rust_alloc_zeroed@GOTPCREL] ``` </details> changelog: [`slow_vector_initialization`]: clarify why `Vec::new()` + resize is worse than `vec![0; len]`
[`filter_map_bool_then`]: Don't ICE on late bound regions Fixes rust-lang#11309 Also lints `&NonCopy` now, since any `&` is `Copy`. That was accidental, but it seems that this is a consequence (or improvement!) of this fix. r? `@Jarcho` changelog: [`filter_map_bool_then`]: Don't ICE on late bound regions
When a mutable binding is shadowed by a mutable binding of the same name in a different scope, mutations in that scope have different meaning. This commit fixes spurious `redundant_locals` emissions on such locals.
Rustup r? `@ghost` cc `@max-niederman` With the latest sync, I'm getting a lot of FP in the `redundant_locals` lint you recently added. Any ideas where this could come from? changelog: none
…_mutated, r=Alexendoo redundant_locals: fix FPs on mutated shadows Fixes rust-lang#11290. When a mutable binding is shadowed by a mutable binding of the same name in a different scope, mutations in that scope have different meaning. This PR fixes spurious `redundant_locals` emissions on such locals. cc `@Centri3,` `@flip1995` changelog: [`redundant_locals`]: fix false positives on mutated shadows
Some changes occurred in src/tools/clippy cc @rust-lang/clippy |
Well, I guess the revert was entirely unnecessary 😅 I didn't expect it to get into this sync, ah well |
Better save than sorry :) Thanks for keeping up with stuff like this! |
@bors r+ p=1 yeah totally fine to be eager about reverts, syncs can fail for a load of reasons just try to pay attention to the syncs when they happen so the revert gets properly included |
☀️ Test successful - checks-actions |
Finished benchmarking commit (b03864d): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 632.877s -> 631.671s (-0.19%) |
r? @Manishearth
cc @Centri3 This reinstates the
filter_map_bool_then
lint #114715, since I think you fixed the ICE in beb57f0 which is included in this sync.